Software applications, e.g., a social networking application, typically release new features to users of the application in a phased manner. For example, the application releases a feature to a subset of the users in a first phase, to another subset of users in a second phase and so on. The number of users to whom the features are made available is increased gradually over a period of time. The application providers can adopt such a phased manner of releasing the features for various purposes. Generally, many server computing devices (“servers”) can provide application services, and users are associated with one or more of the servers. For example, the load on a servers executing the application can be significantly high if all of the users associated with that server access the new feature at around the same time, thereby degrading the user experience. The load on the server can be managed efficiently when the feature is made available to the users in a phased manner. In another example, if the new feature has any errors or efficiency issues, the server can be overwhelmed with a number of error messages, making it difficult for the application provider to analyze and rectify the errors. If the feature is released in a phased manner, the application provider can monitor the performance of the application for a smaller number of users, analyze and rectify any uncovered errors in the feature, and then proceed with releasing the feature in the next phase to other set of users.
To accomplish this phased manner of releasing the features, the code with new features is typically deployed iteratively to a few servers at a time. However, the process of deploying the code iteratively can be complicated, inefficient and requires more effort. Further, at any particular time, different servers can have different versions of the code. For example, in order to make the new feature available only to a first subset of the users, a first version of the application that has the new feature may have to be deployed on the server which serves the first subset of the users, and the other servers, which serve users other than the first subset, would have a second version of the application that does not have the new feature. When the new feature is to be made available to a second subset of the users, either the first version of the application is deployed on a second server that serves the second subset of users, or the second version of the application executing on the second server is changed to include the new feature, which requires the code of the application on the second server to be changed and redeployed on the second server.
If the criteria for making the feature available changes, e.g., the set of users to whom the feature is to be made available, changes, the code of the application has to be changed to include the new criteria, compiled and redeployed to the servers. Deploying the application multiple times or changing the code multiple times as and when the features are to be made available to a different set of users can be inefficient, incur significant amount of effort, and increase costs. Having different versions of the application executing on different servers can also give rise to consistency problems. Further, if different features are to be made available to different users, the number of versions of the application that can exist can be significantly high, which can amplify the version management problems.